Modern businesses rely on a variety of applications and systems that control and generate information that is critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. The level of access that users are granted may depend on the role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those whom he reports to.
Earlier less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular resource. Upon making a determination that access should be granted, a token is provided to the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser receives a cookie that represents a token that may be used to access the human resources application.
To facilitate the proliferation of access management systems, developers of such systems created agent development kits to allow application developers to easily create agents that are capable of interacting with an access management system on behalf of an application. These agents represent the logic required at the application side, and applications require less code to integrate with and use these agents than they would to include the access management logic directly into the application. However, agents are specific to the access management systems for which the agent toolkit was developed. Therefore, if an enterprise architect or engineer wishes to change the access management system used by a particular application, the agent associated with the application must also be replaced to conform to the requirements of the new access management system. Furthermore, access management systems may have different features, so that one access manager would not offer the services required by the applications in the enterprise, even if the agents were compatible. All of this makes access management systems “sticky,” meaning that it is very difficult or cost-ineffective to switch applications from their reliance on one access management system to another.
As a result of the stickiness of access management systems, many enterprises either use multiple access management systems or use applications that are easily integrated with access management systems that are already employed by the enterprise. Applications are thus organized into “silos,” and many of the applications are unable to take advantage of the services offered by access management systems that they are incompatible with. In such an enterprise, it becomes difficult to roll out new access management features, because integration must be performed for each access management system. In addition, users are often confused by the lack of universal integration, since the demarcation between applications using the same access management system is not easily recognizable to the user.
In cases where applications are all using the same access management system, enterprise architects are often limited in their choice of applications out of a desire to maintain an existing access management system. Therefore, even if a particular application offers superior features, the architect will often choose a different application that is already compatible with or easily integrated with the access management system that is already deployed within the enterprise, sacrificing the superior features to retain consistency.
Present access management solutions face several challenges, and existing products have been under pressure to evolve to seamlessly support emerging enterprise and Internet access management requirements. This evolution has been problematic since products use designs that are impractical to extend to accommodate emerging requirements. As a result, addition of new features is often achieved via newer product components posing disruptive and time consuming integration and implementation process.
When it comes to securing enterprise resources and enabling access to these resources by enterprise users, companies have the freedom to choose and standardize their solution around protocol standards and implementation models that best suit their needs. But when it comes to extranet, there are business motivations to accommodate and attract an expanding base of user communities representing varying levels of trust (such as business partner communities, enterprise customers and general public Internet consumers), and associated interaction models.
Enterprises have to secure varying types of resources spanning different administrative models and problem domains. On the other hand users in an enterprise often need access to resources across many such domains.
Driven by regulatory compliance initiatives such as SOX or M&A activity, enterprise Access Management players need to transition from functional product silos to a process oriented environment that consolidates various legacy stacks such that, access management and control can be applied to all IT assets in a consistent manner. But lack of consistent consolidation architectures and migration frameworks often pose insurmountable implementation challenges.
Access Management vendors have traditionally addressed the above challenges with individual products specialized for specific problem domains. The common elements of access management solutions, namely, types of tokens used to encode assertions, trust model among the parties involved, and the wire protocol standards are all inherently independent issues. But traditional products tend to create tight coupling among these elements.
FIG. 1 illustrates an example of different products tailored for different environments, each representing a specific coupling typical to the environment the product is targeted for. Because of the above tight coupling, multiple individual products need to be glued together to address the heterogeneous problem domains. This gluing/bridging ends up being the weakest link in the overall security posture since the individual products bridged are incompatible in their security models and design patterns.
These independent products are also often based on independent technology stacks, thus compounding the challenge of deploying integrated solutions for customers.